1. Field of the Invention
The present invention generally relates to a method for design auditing by automating ways of auditing data produced by process steps.
2. Description of the Related Art
Since the beginning of design and manufacturing of simple chips and higher level assemblies, it has been important to ensure the correct execution of various programs in the process, use of the correct version of technology data elements, and consistency of design data in some specific applications. Errors could result in incorrect design, build, or test of the product. The first example of an automatic system to provide this was developed by IBM in the 1970s and is described in a paper by P. Case et al., “Design Automation in IBM,” IBM Journal of Research and Development, volume 25, number 5, pages 631-646, September 1981. This host-based system had a framework and an executive program tracking activity by other applications which stored audit records in a design database. It also had an audit rule to list valid technology rule and program levels and required completion codes for applications. There was an AUDIT function which checked all of the audit records against the audit rule and an audit trail which could be included on the release interface to manufacturing. The system handled design level tracking and provided some application sequencing control.
When workstations replaced host computer systems for design, it was necessary to develop a workstation-based system to replace the host-based system. At the same time, certain other needed features were added including a method of operating without requiring a framework and use of a new human-readable data model and audit files. FIG. 1 shows a portion of a conventional workstation system used to audit a product being designed. This process is not necessarily prior art and is not generally known to those ordinarily skilled in the art at the time of filing the patent application. The design process 24 uses the VLSI InCore (VIM) 22 containing netlist and physical design data as its design data model. Chip release steps 20 (various checking programs and data generation programs) produce an audit trail as “library usage files” (LUFs) 32. The technology developers provide audit rules 34 which contain correct levels of technology rules and required applications and tasks with required completion codes. The Quality Monitor Audit program 26 reads the LUFs and the audit rules and produces an output audit report 29 indicating whether the design passes the audit. The audit rules and LUFs (ascii files) are checksummed to guarantee file integrity.
The methodology portion of the LUF 32 for a program gives information on the program itself, the name of the data object (e.g., chip name) operated on, and results of tasks performed during program execution. The methodology LUF statement-types include:    PROGRAM pgmName executableName moduleDate moduleTime runDate runTime    OBJECT objectName level    TASK taskName completionCode
The parameters on the PROGRAM statement include name of the program (pgmName), name of the code executable (executableName, including path name if possible), compile date of program executable (moduleDate—yy/mm/dd), compile time of program executable (moduleTime—hh:mm:ss), date the program was run (runDate—yy/mm/dd), and time the program was run (runTime—hh:mm:ss).
The parameters on the OBJECT statement include name of the entity (chip or macro) the program is running on (objectName) and the date/time stamp of the entity (level). (The format of the date/time is 0CYYDDDHHMMSS00 where C is the century: 0=19 1=20). The level is used for design data consistency checking external to QM.
The parameters on the TASK statement include the name of the TASK performed (taskName) and the completion code of the TASK (completionCode: 0=success, 4=warning message was issued, 8=error, 12=task was not run or was run on partial data, 16=program did not complete).
FIG. 2 shows the methodology portion of an original LUF. This is the audit trail produced by the VIM chip layout checking program. The PROGRAM statement says that the program name is ChipEdit, the executable is bin/ChipEdit, executable compile date is 2001 Apr. 17, executable compile time is 09:36:02, run date is 2001 Apr. 30, and run time is 15:09:36. There is only one OBJECT statement and it says the program was run on the chip named txplus, which had a time/date stamp 010111714361900. The program has a number of TASKs to be run on every chip. The first TASK is a check to detect nets shorted together (Chip_Edit_net_short) and it was successfully executed (completion code was 0), indicating no nets were shorted. Other tasks included checks for spacing, loops, opens, and other chip layout errors.
To provide PROGRAM and TASK auditing capability, the format of the Audit Rule statements is as follows:    PROGRAM <pgmName> <executableName> <moduleDate> <moduleTime>    TASK <taskName> <maxCompletionCodeAllowed>
The parameters of the PROGRAM have the same meaning as defined above for the LUF. It may be desirable not to audit moduleDate and moduleTime for a program, and in that case the audit rule will have an asterisk after the executableName. The parameters of the TASK statement include the maximum completion code (highest integer) allowed for a task for acceptance for manufacturing (maxCompletionCodeAllowed). This completion code is defined according to the same scheme as used for the LUF.
FIG. 3 shows a portion of an original AUDIT Rule. Note that an ascending alphabetic sort has been done on the fields of each statement, resulting in all the PROGRAM statements being grouped together and all the TASK statements being grouped together. The first PROGRAM statement listed says that the Chip_Edit program name has an executable named Chip_Edit and there is no requirement to audit for module date and module time. The eighth TASK listed is the statement for the Chip_Edit net short check (Chip_Edit_net_short) and it has a maximum allowed completion code of 0 (success is required). The audit rule shows other PROGRAMs and their TASKs, all sorted alphabetically. This loses the parent-child relationships and places a requirement on the TASKs to have unique names in the audit rule and also in the audit system. Also, since only one OBJECT statement is supported in the LUF, the audit rule does not contain any OBJECT statement. All PROGRAMs and TASKs listed in the Audit Rule are assumed to be required to be listed in the LUF.
The QM 26 processes a LUF 32 by reading a record at a time, looking for a record in the audit rule with a matching record type (field 1) and record name (field 2), checking subsequent fields in the record as required by the record type, and reporting an error if a match could not be found or if an error condition was present in the LUF.
This approach worked well for the original simple application auditing requirements. However, the inventors discovered that it did not work for more complex applications and methodologies. An analysis of the test generation process showed that the application is executed in major unique groupings of TASKs. A TASK might have the same name between such groupings. It was important to preserve these parent-child relationships while auditing. Also, a method was needed to report new data information in the LUF and to audit for its values against legal values described in the audit rule. Furthermore, complex conditions existed as to whether PROGRAMs, TASKs, groupings of TASKs, and the new information statements were required, optional, or prohibited according to global conditions of the part number being processed. There was no way to determine these conditions for a part number and audit whether the correct processing had occurred. Without these new capabilities, it was impossible to ensure that correct test methodology had been followed.
Similarly, the layout methodology became more complex to handle methodology differences. For example, the area array footprint of flip-chip solder bumps supports placement of I/O circuits internal to the die and requires additional power routing for them. This means that the checking program must successfully execute additional TASKs in this case but must not attempt these TASKs in the case of a peripheral I/O image.
In view of these requirements, the original audit capability shown in FIG. 1 required major improvements. An automated solution was still required to eliminate human error and achieve product delivery times previously committed to customers.